... using the temporary section type code 0x40000020
(`clang -c -Wa,--crel,--allow-experimental-crel`). LLVM will change the
code and break compatibility (Clang and lld of different versions are
not guaranteed to cooperate, unlike other features). CREL with implicit
addends are not supported.

---

Introduce `RelsOrRelas::crels` to iterate over SHT_CREL sections and
update users to check `crels`.

(The decoding performance is critical and error checking is difficult.
Follow `skipLeb` and `R_*LEB128` handling, do not use
`llvm::decodeULEB128`, whichs compiles to a lot of code.)

A few users (e.g. .eh_frame, LLDDwarfObj, s390x) require random access. Pass
`/*supportsCrel=*/false` to `relsOrRelas` to allocate a buffer and
convert CREL to RELA (`relas` instead of `crels` will be used). Since
allocating a buffer increases, the conversion is only performed when
absolutely necessary.

---

Non-alloc SHT_CREL sections may be created in -r and --emit-relocs
links. SHT_CREL and SHT_RELA components need reencoding since
r_offset/r_symidx/r_type/r_addend may change. (r_type may change because
relocations referencing a symbol in a discarded section are converted to
`R_*_NONE`).

* SHT_CREL components: decode with `RelsOrRelas` and re-encode (`OutputSection::finalizeNonAllocCrel`)
* SHT_RELA components: convert to CREL (`relToCrel`). An output section can only have one relocation section.
* SHT_REL components: print an error for now.

SHT_REL to SHT_CREL conversion for -r/--emit-relocs is complex and
unsupported yet.

Link: https://discourse.llvm.org/t/rfc-crel-a-compact-relocation-format-for-elf/77600

Pull Request: llvm#98115

(cherry picked from commit 0af07c0)

llvm#99888 added a check (and
corresponding options) to flag uses of `#pragma mc_func` on AIX.

This PR turns on the check by default.

(cherry picked from commit b933517)

…ng EEW (llvm#101152)

As noted in
https://github.com/llvm/llvm-project/pull/100367/files#r1695448771, we
currently fold in vmerge.vvms and vmv.v.vs into their ops even if the
EEW is different which leads to an incorrect transform.

This checks the op's EEW via its simple value type for now since there
doesn't seem to be any existing information about the EEW size of
instructions. We'll probably need to encode this at some point if we
want to be able to access it at the MachineInstr level in llvm#100367

Before commit 705788c the checker alpha.unix.BlockInCriticalSection
"recognized" the methods `std::mutex::lock` and `std::mutex::unlock`
with an extremely trivial check that accepted any function (or method)
named lock/unlock.

To avoid matching unrelated user-defined function, this was refined to a
check that also requires the presence of "std" and "mutex" as distinct
parts of the qualified name.

However, as llvm#99628 reported, there are standard library implementations
where some methods of `std::mutex` are inherited from an implementation
detail base class and the new code wasn't able to recognize these
methods, which led to emitting false positive reports.

As a workaround, this commit partially restores the old behavior by
omitting the check for the class name.

In the future, it would be good to replace this hack with a solution
which ensures that `CallDescription` understands inherited methods.

(cherry picked from commit 99ae2ed)

Following up on the RFC discussion, this is clarifying that the main
purpose and effect of the -Ofast deprecation is to discourage its usage
and that everything else is more or less open for discussion, e.g. there
is no timeline yet for removal.

---------

Co-authored-by: Aaron Ballman <[email protected]>
(cherry picked from commit 48d4d4b)

This enables "-rc" suffix in release branches.

(cherry picked from commit 25efb74)

)

This patch refactors the handling of reduction to eliminate layering
violations.

* Introduced `getReductionIntrinsicID` in LoopUtils.h for mapping
recurrence kinds to llvm.vector.reduce.* intrinsic IDs.
* Updated `VectorBuilder::createSimpleTargetReduction` to accept
llvm.vector.reduce.* intrinsic directly.
* New function `VPIntrinsic::getForIntrinsic` for mapping intrinsic ID
to the same functional VP intrinsic ID.

(cherry picked from commit 6d12b3f)

Since llvm#99276 has been landed, the dependency has become redundant.

This reverts commit aa94a43.
(llvmorg-19-init-17718-gaa94a43178e1)

(cherry picked from commit 5bf0859)

```
  SanitizerCommon-ubsan-sparc-Linux :: Linux/signal_line.cpp
```
currently `FAIL`s on Linux/sparc64 (32 and 64-bit) for `n == 2`. Instead
of the expected `SIGSEGV`, the test dies with `SIGBUS`. `strace` reveals
that this is due to a unaligned access:
```
--- SIGBUS {si_signo=SIGBUS, si_code=BUS_ADRALN, si_addr=0x1} ---
```
which is to be expected on a strict-alignment target like SPARC. Fixed
by changing the invalid pointer to be better aligned.

Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`.

(cherry picked from commit 94394ca)

llvm#101011)

…parc64

```
  SanitizerCommon-Unit :: ./Sanitizer-sparc-Test/SanitizerCommon/InternalMmapWithOffset

```
`FAIL`s on 32-bit Linux/sparc64:
```
projects/compiler-rt/lib/sanitizer_common/tests/./Sanitizer-sparc-Test --gtest_filter=SanitizerCommon.InternalMmapWithOffset
--
compiler-rt/lib/sanitizer_common/tests/sanitizer_libc_test.cpp:335: Failure
Expected equality of these values:
  'A'
    Which is: 'A' (65, 0x41)
  p[0]
    Which is: '\0'
```
It turns out the `pgoffset` arg to `mmap2` is passed incorrectly in this
case, unlike the 64-bit test. The caller, `MapWritableFileToMemory`,
passes an `u64` arg, while `mmap2` expects an `off_t`. This patch casts
the arg accordingly.

Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`.

(cherry picked from commit 1c25f2c)

…g SME attrs" (llvm#100991) (llvm#100996)

Test `aarch64-sme-inline-streaming-attrs.c` caused some buildbot
failures, because the test was missing a `REQUIRES: aarch64-registered
target`. This was because we've demoted the error to a warning, which
then resulted in a different error message, because Clang can't actually
CodeGen the IR.

(cherry picked from commit 389679d)

…lvm#92103)

Also changes the behaviour of `__builtin_is_layout_compatible`

None of the historic nor the current definition of layout-compatible
classes mention anything about base classes (other than implicitly
through being standard-layout) and are defined in terms of members, not
direct members.

…gisters. (llvm#94628)

On PowerPC there are 128 bit VSX registers. These registers are half
overlapped with 64 bit floating point registers (FPR). The 64 bit half
of the VXS register that does not overlap with the FPR does not overlap
with any other register class. The FPR are the only subregisters of the
VSX registers but they do not fully cover the 128 bit super register.
This leads to incorrect lane masks being created.

This patch adds phony registers for the other half of the VSX registers
in order to fully cover them and to make sure that the lane masks are
not the same for the VSX and the floating point register.

(cherry picked from commit 53c37f3)

…script (llvm#101647)

Current CSA logic does not expect `LazyCompoundValKind` as array index.
This may happen if array is used as subscript to another, in case of
bitcast to integer type.

Catch such cases and return `UnknownVal`, since CSA cannot model
array -> int casts.

Closes llvm#94496

(cherry picked from commit d96569e)

In terms of bug catching capability, `_FORTIFY_SOURCE` does not perform
as well as some dynamic instrumentation tools. When a sanitizer is used,
generally `_FORTIFY_SOURCE` should be disabled since sanitizer runtime
does not implement most `*_chk` functions. Using `_FORTIFY_SOURCE`
will regress error checking (asan/hwasan/tsan) or cause false positives
(msan).

`*printf_chk` are the most pronounced `_chk` interceptors for
uninstrumented DSOes (https://reviews.llvm.org/D40951).

glibc 2.40 introduced `pass_object_info` style fortified source for some
functions ([1]). `fprintf` will be mangled as
`_ZL7fprintfP8_IO_FILEU17pass_object_size1PKcz`, which has no associated
interceptor, leading to printf-fortify-5.c failure.

Just disable the test. Fix llvm#100877

[1]: https://sourceware.org/pipermail/libc-alpha/2024-February/154531.html

Pull Request: llvm#101566

(cherry picked from commit bbdccf4)

This reverts commit b933517.

(cherry picked from commit dd7a4c3)

(cherry picked from commit 8f39502)

…1820)

llvm#98489 resurrected an [old patch](https://reviews.llvm.org/D10833) that
was adding new libclang functions. That PR got merged with old `LLVM_13`
symbol versions for new functions. This patch fixes this oversight.

(cherry picked from commit 2bae7ae)

```
  UBSan-Standalone-sparc :: TestCases/Misc/Linux/diag-stacktrace.cpp
```
`FAIL`s on 32 and 64-bit Linux/sparc64 (and on Solaris/sparcv9, too: the
test isn't Linux-specific at all). With
`UBSAN_OPTIONS=fast_unwind_on_fatal=1`, the stack trace shows a
duplicate innermost frame:
```
compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:14:31: runtime error: execution reached the end of a value-returning function without returning a value
    #0 0x7003a708 in f() compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:14:35
    llvm#1 0x7003a708 in f() compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:14:35
    llvm#2 0x7003a714 in g() compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:17:38
```
which isn't seen with `fast_unwind_on_fatal=0`.

This turns out to be another fallout from fixing
`__builtin_return_address`/`__builtin_extract_return_addr` on SPARC. In
`sanitizer_stacktrace_sparc.cpp` (`BufferedStackTrace::UnwindFast`) the
`pc` arg is the return address, while `pc1` from the stack frame
(`fr_savpc`) is the address of the `call` insn, leading to a double
entry for the innermost frame in `trace_buffer[]`.

This patch fixes this by moving the adjustment before all uses.

Tested on `sparc64-unknown-linux-gnu` and `sparcv9-sun-solaris2.11`
(with the `ubsan/TestCases/Misc/Linux` tests enabled).

(cherry picked from commit 3368a32)

Crash seems to be caused by the check function not handling inline
namespaces correctly for some instances. Changed how the Replacer is got
from the MatchResult now which should alleviate any potential issues

Fixes llvm#100406

(cherry picked from commit 0762db6)

This adds release binary builds for the 4 platforms currently supported
by the free GitHub Action runners:

* Linux x86_64
* Windows x86_64
* Mac x86_64
* Mac AArch64

The test stages for these are known to fail, but the creating and
upoading of the release binaries should pass.

(cherry picked from commit 247251a)

(cherry picked from commit 18dee70)

…ranch (llvm#100805)

If we pull from the release tag, then if there is a bug in one of the
actions on the release tag, then we can never do a build for that tag.
Pulling from main will allows us to fix bugs in the actions we use to
build the releases.

(cherry picked from commit b0860b2)

Introduced in b0860b2.

(cherry picked from commit d41f565)

…t workspace (llvm#100845)

Otherwise, the checkout step will override them.

(cherry picked from commit 41003ff)

…acos-14 (llvm#101774)

python3 wasn't able to see modules installed by pip, so we need to use
the setup-python action to ensure that the default pip and python3 both
use the same prefix.

See actions/runner-images#10385

(cherry picked from commit 59476c9)

…tion (llvm#101569)

The old version in the llvm/actions repo stopped working after the
version variables were moved out of llvm/CMakeLists.txt. Composite
actions are more simple and don't require javascript, which is why I
reimplemented it as a composite action.

This will fix the failing abi checks on the release branch.

(cherry picked from commit 14837af)

Fixes llvm#101859.

If we have at least 2 ranges, we have to try to merge the last and first
ones to handle the wrap range.

(cherry picked from commit 4377656)

…rbose_trap support (llvm#110161)

We should have been checking against 1700, not 17000, which was a typo.

(cherry picked from commit 1eba879)

Large scratch offset with one on highest bit selected as negative,
negative offset has same binary representation in 16 bits as large
unsigned offset.

(cherry picked from commit e9d12a6)

…lvm#110256)

Use i32 for offset instead of i16, this way it does not get interpreted
as negative 16 bit offset.

(cherry picked from commit 83fe851)

Until llvm#103056 lands
or another more appropriate check can be found.

This test fails on Ubuntu Focal where zdump is built with 32 bit time_t
but passes on Ubuntu Jammy where zdump is built with 64 bit time_t.

Marking it unsupported means Linaro can upgrade its bots to Ubuntu
Jammy without getting an unexpected pass.

(cherry picked from commit 6f6422f)

This fixes the test on Arm 32 bit Ubuntu Jammy where time_t is 32 bit.

(cherry picked from commit cdd608b)

…lvm#90967)

Multiple invocations of the pass could interfere with eachother,
preventing some undefs being initialised.

I found it very difficult to create a unit test for this due to it being
dependent on particular allocations of a previous function. However, the
bug can be observed here: https://godbolt.org/z/7xnMo41Gv with the
creation of the illegal instruction `vnsrl.wi v9, v8, 0`

…ssing NoCD8 (llvm#109579)

Promoted KMOV* was encoded with CD8 incorrectly, see
https://godbolt.org/z/cax513hG1

(cherry picked from commit 0d334d8)

This was mistakely changed by llvm#109579, which doesn't match with other
EVEX decoding.

(cherry picked from commit 70529b2)

Fix counted_by attribute for cases where the flexible array member is
accessed through struct pointer inside another struct:

```
struct variable {
        int a;
        int b;
        int length;
        short array[] __attribute__((counted_by(length)));
};

struct bucket {
        int a;
        struct variable *growable;
        int b;
};
```

__builtin_dynamic_object_size(p->growable->array, 0);

This commit makes sure that if the StructBase is both a MemberExpr and a
pointer, it is treated as a pointer. Otherwise clang will generate to
code to access the address of p->growable intead of loading the value of
p->growable->length.

Fixes llvm#110385